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INTEGRATED ADVANCE SCHEDULING OF INDETERMINATE PROJECTS 
IN AN INTEGRATED DEVELOPMENT PROCESS 



CROSS-REFERENCE TO RELATED APPLICATIONS 
[0001] This application addresses subject matter related to U.S. Patent Application Ser. No. 
10/429,615, filed May 5, 2003 and entitled "Defining and Sizing Feasible Approaches to Business 
Needs within an Integrated Development Process" and U.S. Patent Application Ser. No. 
10/643,334, filed August 18, 2003 and entitled "Method for Discovering Functional and System 
Requirements in an Integrated Development Process," both of which are incorporated herein by 
reference. 

STATEMENT REGARDING FEDERALLY SPONSORED 
RESEARCH OR DEVELOPMENT 

[0002] Not applicable. 

REFERENCE TO A MICROFICHE APPENDIX 
[0003] Not applicable. 

FIELD OF THE INVENTION 
[0004] The present disclosure relates to the use of consistent checkpoints in the process of 
enterprise-wide software development to allow significant events to occur in a predictable, 
scheduled manner. More specifically, a method is provided for determining the appropriate size 
for a software release and for reserving the appropriate resources needed in an enterprise-wide 
software development project. 

BACKGROUND OF THE INVENTION 
[0005] Technologies that address the problem of integrating existing computer and 
communication systems with new systems in an organized, efficient, and economically scaleable 
manner can be referred to collectively as Enterprise Application Integration (EAI). The software 

1 

13147.01/4000.11100 



engineering discipline that addresses EAI and the underlying integration issue is the domain of 
enterprise architecture. Architectural engineers typically realize architectures by specifying the 
components to be used (hardware, software, network, etc.); depicting how the components fit 
together (where and when in the process); clearly defining the interfaces and boundaries between 
components; setting guidelines and standards; and determining the layers, services, dependencies, 
and abstraction levels. 

SUMMARY OF THE INVENTION 

[0006] An embodiment of the invention is a method for scheduling resources to be used in a 
software development project. The method can comprise a customer providing information 
regarding a software development project to be completed. A planning department, which could 
be an IT department or a release management group, initially reviews the provided information and 
provides initial feedback prior to completing a detailed requirements analysis. The detailed 
requirements analysis can include any or all of a functional requirements modeling step, a system 
requirements modeling step, an application integration modeling step, and a contract development 
step. The planning department reserves resources for the project based on the information prior to 
completing the detailed requirements analysis. After reserving the resources and completing the 
detailed requirements analysis, the planning department can offer the customer a contract 
describing the resources to be used for the project and, upon approval of the contract by the 
customer, the planning department can schedule the reserved resources as agreed upon in the 
contract. 

[0007] An altemative embodiment is a method for scheduling resources to be used in a 
software development project. The method can consist of a customer submitting information about 
the software development project to an IT department (which may be represented by a release 
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management group). The IT department analyzes the feasibility of the project and estimates its 
cost. Based on the analysis of feasibility and estimate of cost, the customer decides whether to 
proceed with the project and, upon deciding to proceed, the customer prioritizes and funds a more 
detailed analysis for the project. At this point, the IT department reserves resources for the project. 
The IT department then models at least one set of requirements for the project. Upon completion 
of the requirements modeling, the IT department gives the customer an estimate of the resources 
needed for the project. Upon approval of the estimate by the customer, the IT department books 
the resources. 

[0008] During the requirement modeling, the IT department can determine whether the results 
of the modeling of a requirement indicate that modifications to the requirement are needed. When 
modifications are needed, alerts can be sent to projects dependent on a project for which 
modifications are needed in the reserved resources, where the alerts inform the dependent projects 
that further analysis may be needed. The reserving of resources can be aided by a tool that uses 
past experience and the information submitted by the customer as input and produces an estimate 
of the resources required as output. 

[0009] Another altemative embodiment is a method for scheduling software releases for a 
computer system. The method can consist of planning a series of releases for a given time period, 
each release having an initial allocation of capacity. Information regarding proposed software 
projects is reviewed and initial estimates of cost and duration for such projects are provided to 
customers for approval to move into detailed analysis. On receiving approval for detailed analysis 
for each project, the plaimed series of releases and the initial estimate of cost and duration for the 
approved project are reviewed and capacity is reserved in a release having available capacity for 
the project approved for further analysis. As detailed analyses and customer feedback change the 
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scope of the projects approved for further analysis, the reserved capacity is adjusted and, where 
available capacity is not present, the reserved capacity is moved to a later release. As detailed 
analyses are completed and projects finally approved, the scheduled reservations are booked in the 
releases. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0010] Figure 1 is a block diagram depicting an embodiment of the packaging and scheduling 
process. 

[0011] Figure 2 is a flowchart depicting an embodiment of the packaging and scheduling 
process. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
[0012] An enteiprise-wide EAI process can be employed to facilitate the integration of 
enterprise architecture. A suitable process, known as the Enterprise Development Process (EDP), 
is described in detail in U.S. Patent Application Ser. No. 10/429,615, filed May 5, 2003 and 
entitled "Defining and Sizing Feasible Approaches to Business Needs within an Integrated 
Development Process" and U.S. Patent Application Ser. No. 10/643,334, filed August 18, 2003 
and entitled "Method for Discovering Functional and System Requirements in an Integrated 
Development Process," both of which are incorporated herein by reference. EDP provides rigor to 
the process of enterprise-wide software development. Consistent checkpoints throughout the 
process allow significant events to occur in a predictable, scheduled manner. The EDP process 
typically comprises five phases: Define, Discover, Design, Develop, and Deploy. An optional 
sixth phase is a Demand phase that addresses feedback for long-term optimization. 
[0013] The Define phase encompasses processes that define the business intent and concepts 
that are aligned with the business intent. Robust concept definition and ensuing communications 
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ensure a proposed approach is on target with what a business wants delivered. Alignment with 
strategic network and information technology (IT) architectures is also facilitated. As a side 
benefit, the Define phase can reduce estimation time averages. 

[0014] The Define phase typically comprises four steps, Intent, Ideation, Feasibility, and 
Estimation. Intent refers to processes that help define the businesses strategic intent through the 
integration of mission, goal, objective, and capability models. Business-related decisions are made 
at this point without consideration of feasibility or design. Ideation encompasses formal and 
informal idea generation and the rigor of idea selection via validation against strategic intent. In 
the Ideation step a problem is defined in the context of Intent and a technical approach to the 
problem is developed. Intent and Ideation are specific to a particular business unit. The Feasibility 
step facilitates determination of technical approaches, test approaches, critical functional impacts, 
impacted systems, and overall feasibihty of concepts prior to Estimation. The Estimation step 
facilitates estimation of level of eflfort to aid with prioritization and investment decisions. An 
appropriate capacity of personnel, hardware, and other resources as needed to complete a project is 
estimated. 

[0015] The Discover phase refers to the processes that help discover fimctional and system 
requirements in support of business requirements. The Discover phase facilitates a "process- 
driven" approach to requirements gathering. The analysis conducted in the Discover phase verifies 
the business processes envisioned and elicits all the requirements of the project. These 
requirements are documented in a centralized repository along with the business and system 
process models, thus enabling traceability and reuse on subsequent projects. As a by-product of 
the Discover phase analysis, it is possible to automatically generate interfaces as well as test 
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workflows and test cases. These automation capabilities shorten the test window and overall 
project cycle time. 

[0016] The Discover phase typically comprises four steps. Functional Requirements Modeling 
(FRM), System Requirements Modeling (SRM), Application Integration Modeling (AIM), and a 
Contract Development Procedure. FRM facilitates identification of functional requirements, 
linked to supporting business requirements. 

[0017] Automated solutions can begin to be sought in the SRM step. SRM facilitates 
identification of system requirements, linked to supporting fimctional requirements. In this step, IT 
personnel can provide packages of options for approaching a problem and business-oriented 
personnel can choose an appropriate option. 

[0018] AIM bridges the complexities of appHcation, messaging, and information components 
into an integrated architecture that supports development, implementation, and maintenance of a 
flexible and robust IT infi-astructure. AIM provides rigorous processes, methodologies, and tools 
to document and vaUdate interfaces between enterprise apphcations and to support software 
development that involves application integration using brokers and middleware components. 
AIM also helps apphcation programmers understand their responsibilities within fimctional and 
process areas. 

[0019] The Contract Development Procedure specifies the steps, timing, and approvals needed 
to produce a valid contract for a project. A standard project contract describing a proposed project 
(also referred to as a concept) is typically created as a result of the Contract Development 
Procedure. 

[0020] The Define and Discover phases are the portions of EDP in which a software 
development project moves from a concept to a well-defined project. At the end of the Discover 
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phase, an agreement is reached between a customer and an IT group regarding the personnel, 
computing equipment, and other resources that will be dedicated to a project. As used herein, the 
term "customer" can refer to a business unit within an enterprise to which an IT department within 
the enterprise is providing services. 

[0021] Multiple software projects are typically bundled in releases, where a release can be 
defined as a standard, periodically released package that can accommodate software projects of 
varying sizes and complexities. A release typically has a defined a number of hours of labor 
capacity as well as other resource capacity. A defined number of releases are typically completed 
in a year and are typically spread throughout a year. Releases can be defined as either major or 
minor, where a major release has a larger labor capacity and uses more computing resources 
compared to a minor release. As an example, an enterprise might schedule five major releases 
with 100,000 hours of capacity each and four minor releases with 50,000 hours of capacity each, to 
be completed at predefined intervals throughout the year. 

[0022] Testing of the software in a software project is typically done before a release is 
released. Testing is generally done in computing labs and can be limited by the equipment 
available in the labs. For example, if the equipment in the labs can accommodate only five 
projects at a time that use a fi-ame relay service, then no more than five such projects can be 
packaged in a release. 

[0023] Software projects are typically placed into releases based on the number of hours 
estimated to be needed to complete the project, the desired completion date for the project, and the 
availability of personnel, lab equipment, and other resources in the upcoming releases. 
Traditionally, a software project was targeted for a particular release only when all of the 
requirements and costs for the project were definitively determined. That is, cross-organizational 
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impact analysis, scheduling, and packaging of projects into releases did not occur until an analysis 
phase was complete and the requirements and costs of the project were signed off This analysis 
phase can be viewed as being roughly equivalent to the Discover phase in EDP. When the analysis 
phase was complete, the appropriate resources, such as personnel and computing equipment, 
would be committed for the project based on the complexity of the project. At this late stage in the 
process, circumstances may have changed and any of the required resources may not be available 
and hence a project might have to be rescheduled, redesigned, rescoped, or abandoned, hence 
introducing an adverse impact on the business. 

[0024] The packaging and scheduling of releases can be made more efficient and effective by 
estabUshing a process to reserve capacity in standard releases earlier in the development life cycle. 
The present disclosure reserves resources and capacity in standard releases at a point in the project 
development Hfecycle prior to the point when requirements are definitively set. This allows better 
management of a customer's expectations on delivery times for software projects. It also allows 
adjustments to be made to projects and/or schedules during the evaluation, analysis, and 
requirements setting phases of project development. This can prevent the unanticipated adverse 
impact on project scope, cost, and/or schedule. 

[0025] hi one embodiment, a planning department receives estimates fi-om its customers of the 
time required for proposed projects in the next year. More specifically, the projects may be 
software development projects and the planning department may be an IT department, where the 
term "IT department" can refer to any organization within an enterprise responsible for system 
planning of projects. Sub-groups of the planning department may include release management 
groups acting under the overall plarming department (or in one embodiment acting under the IT 
department). For the purposes of this disclosure, where the "planning department's" activities are 
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discussed, this could also include the release management group(s)' activities where the release 
management group is a sub-group of the planning department. Regardless of the particular title 
these groups or departments hold within an organization, the basic function they accomplish and 
roles they play reasonably apply and would be understood by those of skill in the art. The IT 
department adds the estimates from all of its customers to get a total amount of work for the year. 
Those hours are then divided into releases throughout the year. The number and capacity of the 
releases is determined by the total number of hours and available resources. For contingency, an 
extra percentage can be added to the hours allocated to each release. 

[0026] As projects approach and/or enter the pipeline, they are then assigned to the different 
releases based on certain reservation criteria such as the projected development cycle, the 
preliminary test approach as determined in the Feasibility step, the level of effort determined in the 
Estimation step, network and IT architecture, the type of platform required, the type of lab 
required, the available resources in the required lab, dependencies with other projects, the available 
capacity in the target release, and the available workforce in the required areas. 
[0027] The release management system can be integrated with EDP at several points in the 
scheduling process, as illustrated in the embodiment of Figure 1. Only the Define 114 and 
Discover 116 phases of the EDP process 112 are shown; the Design, Develop, and Deploy phases 
are not shown. As discussed previously, the Define phase 1 14 comprises Intent 118, Ideation 120, 
Feasibility 122, and Estimation 124. The Discover phase 116 comprises FRM 128, SRM 130, 
AIM 132, and Contract Development 134. 

[0028] In the Feasibility step 122, a customer provides information regarding a proposed 
project (a concept) to an IT department. The information might include the customer's estimates 
of the labor hours needed, the computing equipment needed, and other relevant parameters. The 
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customer also typically provides a target date for completion of the proposed project. The IT 
department then assesses the information provided by the customer and determines if the 
customer's expected delivery date for the proposed project is feasible. If the date is deemed 
infeasible, the customer may either revise or abandon the proposed project. If the date is 
considered feasible, the process moves to the Estimation step 124. 

[0029] In the Estimation step 124, the IT department manages the customer's expectations 136 
by looking at the estimated project costs, the estimated level of effort, and the typical project 
duration, and giving the customer an estimate, based on past experience, of the likely duration of 
the proposed project. The IT department then tries to estimate which release(s) the proposed 
project will be placed in. In some embodiments, a fixed estimated completion date is not given 
since the start date may not be known. 

[0030] Between the Define 114 and Discover 116 phases, a prioritization and fimding step 126 
can occur. This step is not part of EDP 1 12 but is a process performed by the customer in which 
the customer considers the information provided by the IT department in the Define phase 114. At 
this point the customer can decide whether to fimd further analysis of a proposed project, re-scope 
the proposed project by sending it back to the Define phase 114 for revision under a modified 
scope or conditions, or cancel the proposed project. If further analysis is approved, the proposed 
project (or concept) becomes an actual project (hereinafter referred to as simply a "project") and 
the customer prioritizes and funds the project. The IT group can then reserve capacity 138 and a 
target schedule implementation for the project in the appropriate release. 

[0031] In the illustrated embodiment, the reservation is confirmed at the end of each step in the 
Discover phase 116. The confirmations 140 ensure that the reservation criteria for placing the 
project in the release, such as available lab resources and available capacity in the release, are still 
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being met. At each point where the reservation is confirmed, the progress of the entire project can 
be reviewed in addition to the review of the impact of changes that occurred in that module. If 
discrepancies are found between the estimates and the actual progress of the project, the 
appropriate actions can be taken, such as revising the estimate, sending the project back to the 
Define phase 1 14, changing the number of personnel assigned to the project, or using different test 
equipment, hi alternative embodiments with a more generic analysis phase, confirmation checks 
during analysis may occur at logical breakpoints in the analysis process, at specific timed intervals 
(e.g., weekly, monthly, etc.), or not at all. 

[0032] At the end of the Discover phase 1 16, the IT department gives the customer a revised 
refined estimate of the resources needed for the project along with, in some embodiments, a 
proposed schedule for the project and then offers the customer a final contract. If the customer 
approves the contract, the reservation is booked 142 and resources are committed. This means that 
the schedule is set, capacity in the release is locked, and a formal change request must be submitted 
to make any changes. In some embodiments, a penalty must be paid to make any changes, either 
directly in slipping the release date or in additional overtime assessment, or indirectly through the 
adverse impacts on the company of wasted efforts prior to the change request. 

[0033] The managing of customer expectations 136, the reserving of capacity 138, the 
confirming of capacity 140, and the booking of reservations 142 collectively comprise one 
embodiment of the packaging and scheduling process 144. 

[0034] A flowchart depicting steps that might be taken in an embodiment of the scheduling 
process is shown in Figure 2. In box 212, a customer submits a concept for a software 
development project to an IT group. In box 214, the IT group analyses the feasibility of the 
concept and estimates its cost. The IT group gives the feasibility and estimation data to the 
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customer in box 216. In box 218, the customer decides whether or not to proceed with the concept. 
Upon deciding to proceed, the customer prioritizes and fiinds the concept in box 220. The concept 
then becomes a project in box 222. In box 224, the IT group reserves capacity in an appropriate 
release. In box 226, the IT group performs requirements modehng in the Discover phase of EDP. 
In box 228, throughout the Discover phase, the IT group confirms that the project is meeting its 
estimates. At the end of the Discover phase, the IT group gives the customer an updated estimate 
in box 230. In box 232, the customer decides whether or not to proceed with the project. If the 
customer decides to proceed, the appropriate resources are booked in the appropriate release in box 
234. 

[0035] When a project is validated against the reservation criteria throughout the Discover 
phase, it can be found that the project no longer meets its reservation criteria. For example, the 
number of labor hours needed on the project may exceed the estimate. In this case, the project 
might slip out of its release. Also, if there is a change of scope during Discover, the project might 
have to be moved and may slip to a different release. If a project slips, it can move to the next 
available and appropriate release unless compelling business reasons mandate an exception 
handling process. Extra capacity in a release resulting jfrom a project slipping fi-om that release can 
be used for exception handhng or to move other projects into the release. 

[0036] As an altemative to a project slipping, the project's sponsor can request a change to the 
release capacity threshold. A request to change the release capacity threshold typically must be 
accompanied by compelling business reasons supported by the executive management of the 
sponsoring unit and, in some embodiments, by the IT department. Changes to the release capacity 
threshold are typically considered on a case-by-case basis and approved by executive management 
or by a committee they designate. 
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[0037] The projects packaged in a release can have dependencies on other projects in the 
release. That is, a first project may need to be completed successfully in order for a second project 
to be completed successfully. If the first project slips from its release, the requirements for the 
second project might need to change in order for the second project to avoid failure. In an 
embodiment of the disclosure, when a project slips, all projects dependent on that project are sent 
alerts informing them that their requirements may have changed. 

[0038] As described above, the process of assigning projects to releases can be based on 
several reservation criteria such as the estimated level of effort, the availability of personnel, and 
the availability of lab equipment, A tool such as a spreadsheet or an expert system can be used to 
facilitate this process. Experience gained fi-om observing the ultimate size of projects having 
particular characteristics can be made available to the tool. When an estimate of the likely size of a 
new project is to be made, the known characteristics of the project can be entered into the tool. 
The tool then compares those characteristics with the characteristics of similar past projects and, 
based on experience fi-om those projects, provides an estimate of the resources needed for the new 
project. With the developed information, some embodiments of the tool can also then generate a 
schedule for the projects and releases. 

[0039] Although only a few embodiments of the present invention have been described, it 
should be understood that the present invention may be embodied in many other specific forms 
without departing firom the spirit or the scope of the present invention. The present examples are to 
be considered as illustrative and not restrictive, and the invention is not to be limited to the details 
given herein, but may be modified within the scope of the appended claims along with their full 
scope of equivalents. 
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